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President's Message 


Gary Mitchell, WB6YRU 


First of all, I‘d like to congratulate 
our very own Bob Vallio W6RGG 
(DXSPN representative on the NCPA 
board) for his election to ARRL Pacific 
Division Vice Director. 


Bylaw change 

Our bylaws were somewhat 
restrictive as to when we hold our annual 
general meeting. Experience has 
demonstrated that we get a better turn- 
out if we hold our meeting at a time and 
place where members already tend to be- 
-such as Pacificon. In order to take 
advantage of such things, we had to ease 
up a bit on those restrictions. 

At the last general meeting the 
membership did just that. The bylaws 
now specify that there must be an 
annual meeting, but the board sets the 
date. It now also specifies that written 
notice must be given at least 30 days 
before the meeting. 

It is believed this change will give 
us the needed flexibility to set the 
meeting date and place more to our 
advantage without diluting the basic 
purpose and need for an annual general 
meeting. 


Spectrum Management 
group” meeting. 
At Pacificon ‘99, representatives 


“working 
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from NARCC, NCPA, and others held a 
meeting on the topic of spectrum 
management (i.e. band planning) for the 
region. 

As most of you already know, we’ve 
had difficulty working with NARCC on 
band planning in the past. It seems we 
aren’t the only ones. Most of the 
meeting consisted of an airing of past 
grievances and problems. The idea was 
to establish the kinds of problems we’ve 
all been having and figure out how to go 
from here. 

The consensus was that we all need 
to work together on spectrum 
management. One point of contention 
was the structure of any spectrum 
management committee or group. The 
NARCC leadership continues to insist 
that NARCC should host or sponsor any 
such group. This isn’t a new position for 
NARCC; however, the consensus 
seemed agree with the NCPA that no one 
entity should be in a position to 
dominate such a group. But the NARCC 
leadership was not ready to throw in the 
towel on this point. 

It was decided (suggested by our 
new ARRL director Jim Maxwell) that 
we all exchange e-mail addresses and 
keep the discussion going. Jim collected 
the addresses and a sent a brief note to 
all the participants with the list. I was 
the first to try to keep the ball rolling 
with a posting of my version of the 
minutes and invited others to do the 
same. Unfortunately, the whole thing 
seems to have stalled. 
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Later I sent a couple of messages to 
John K3ZJJ (current president of 
NARCC) including a rough draft of the 
complete band plan that we’d been 
working on...no response yet. I’m happy 
to report Jim Maxwell has also been 
trying to keep things going. 


Packet segment at 70 cm 

We’ve been working on allocating a 
segment for digital at 70 cm for a long 
time. Despite some arguments and 
complications over some time, it finally 
got done! 433.0-434.0 is now digital. 

It’s about time for there to be at 
least one digital segment in that band, 
right? I thought so. However, I learned 
at the spectrum management meeting 
(above) that we had effectively re- 
invented the wheel on this point! 
Reportedly, some ten or twelve years 
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ago NARCC and NCPA had agreed that 
this very same segment would be digital. 

At that meeting, representatives 
from NARCC and myself (NCPA) 
agreed to look back in what records we 
could find to substantiate the old plan. I 
found that in the early issues of the 
Downlink, there was indeed digital 
allocations made at this segment. There 
were also a few articles which talked 
about meeting with NARCC and 
establishing the 433 segment for digital. 

For some reason, this segment was 
quietly dropped from the digital band 
plan a few years later. It’s not clear 
why. The NARCC representative wasn’t 
able to find out much more. It was his 
recommendation that we simply adopt 
the old band plan for that segment and 
go from there. I agreed. 

The channel allocations you see in 
the latest digital band plan (elsewhere in 
this issue) for 70 cm is the result. 
Allocations there are still a work in 
progress, but at least we finally have an 
official place for digital at 70 cm that we 


can work with. 


Multicast 
Why Multicast on Ham Radio? 


Have you ever watched the LAN send 
the same chat message, or the same 
PBBS message over and over again to 
multiple recipients at the same time? 
This is such a waste, it seems like 
someone should be working on a 
solution. The answer is that yes, people 
have been working on this, and the result 
is IP Multicasting. 


IP Multicast is a technology designed to 
allow broadcast packets to be sent across 
many lans on the internet. Unlike 
normal broadcast packets, which are 
limited to the local networks, multicast 
packets can travel through routers and 
over the internet to everyone interested 
in receiving that data. 


Applications where data needs to be sent 
from a _ single source to many 
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destinations are candidates for using IP 
multicast rather than a unicast IP 
program. For example, with a traditional 
chat room system, typically a set of 
computers act as chat servers. Users 
connect to the chat servers, and then the 
chat servers negotiate among themselves 
how data is transmitted among them. 
For each user connected to a chat server, 
the server needs to send out a packet for 
each user -- even if they are on the same 
LAN. The connections between chat 
servers result in difficult code in the 
servers themselves to arrange for routing 
of packets. 


In comparison, with an ip multicast chat 
room, users would broadcast chat 
packets to all users with a single 
'sendblock' command. The routers would 
be responsible for delivering the chat 
messages to all users. The routers 
should be smart enough to eliminate 
duplicate packets sent over the same data 
pipes. IP Multicast is an unreliable UDP 
style mechanism, so some system needs 
to be added to ensure the reliable, or 
even likely, delivery of packets. With an 
IP Multicast chat system, there would be 
no chat servers. All of the logic for 
distributing the chat packets across the 
network are moved down to the OS 
level. As multicast routers are added to 
the system, chat access then is 
automatically available to each new area 
-- since, no new chat server is required. 


That is the job of scaling the size of the 
application is moved to the network -- 
and the application itself can remain 
relatively simple. The ease of 
programming multicast applications may 
then result in more experimentation 
since programmers can create the 
applications without having to build a 
network of servers across the planet -- 
provided there's a multicast network in 
place. 


I believe IP Multicast is a good idea for 
ham radio networks -- as the data that 
travels over ham radio is often of a 
broadcast nature. Whether IP Multicast 
in its current form is suitable for ham 
radio networks remains to be seen -- 


however, the programming API, and 
socket level interfaces to IP Multicast 
are well-designed, and should provide a 
base for applications, both in Windows 
and Linux. 


Here are some basic multicasting 
concepts that I've picked up. 


mrouted 


The program mrouted provides for 
routing of multicast packets. It's 
typically used to connect multiple nets, 
say an ax25 net and an ethernet, or an 
ethernet to another ethernet via a tunnel. 
Mrouted doesn't actually route the 
packets, but instead directs the Linux 
kernel to forward the packets 
accordingly. 


Membership 


IP Multicast works according to a 
concept called 'Membership' A 
setsockopt command called 
IP_ADD MEMBERSHIP | specifies 
which of the multicast IP addresses that 
machine receives packets from. An 
application just specifies that it wishes 
membership in one of the multicast IP's 
in the range 224.0.0.0/4, and then the 
routers take care of the rest, and deliver 
all packets for that multicast IP address 
that are sent anywhere on the network. 


IGMP 


IGMP packets are used by applications 
to indicate to the routers how multicast 
packets should be routed. 


What are the advantages? 


1. IP Multicast is optimized so that 
packets are sent only to the routers that 
need them. The latest mrouted 3.9 
implements a mechanism to reduce this 
traffic. IP Multicast will only send a 
packet once over a tunnel, even if there 
are multiple recipients on the other end. 
Compare this to traditional IP programs, 
which will broadcast a duplicate copy of 
the same data to everyone on the other 
end of the pipe. 
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2. IP Multicast is the result of lots of 
research and testing, and should be 
stable enough for ham radio networks. 
IP Multicast has in it a level of maturity 
that would be extremely difficult to 
duplicate with a ham radio network built 
from scratch. 


3. IP Multicast has a very simple 
programming interface for the 
applications programmer. Most of the 
complexity for distributing of packets 
over a complicated network is placed in 
the operating system. 


4. By building applications using the 
existing IP Multicast programming 
interface, these applications can then 
take advantage of future advances in IP 
Multicast routers. 


5. IP Multicast, though not universally 
supported by Internet service providers, 
is widely supported by OS and software 
venders. So, Win98 and Linux both 
have native support for IP Multicast. 


What are the disadvantages? 


1. Mrouted (the multicast router) is only 
available for UNIX style machines. 
Win98 machines can run multicast 
applications, but as far as I'm aware, they 
cannot act as routers. 


2. Multicast is untested over low speed 
ham radio links. There are certainly 
tuning adjustments which will need to be 
made. 


33 There aren't many multicast 
applications at this time. 


4. Multicast routing isn't supported by 
most ISP's. Anyone interested in 
experimenting in multicast routing will 
need to build their own network. 


5. IP Multicast is an IP based 
technology and inevitably involves the 
overhead associated with IP -- as 
compared to native AX25 systems. 


6. IP Multicast does not guarantee 
delivery, so applications developed for 
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TCP/IP or reliable packet delivery will 
need substantial reworking to use IP 
multicast efficiently. 


How do you get started? 


First, I believe you want to be running a 
Linux version with multicast enabled, 
multicast routing enabled and ax25 also 
enabled. If you haven't done ham radio 
networking before, get your ax25 
devices running first. Go to linux.org 
and look in the support section for the 
HOWTO's. There you'll find the ax25 
howto and the multicast howto. Make 
sure to include IP Multicasting and IP 
Multicast routing when you build your 
kernel. (These options seem relatively 
benign, even if you don't use IP 
Multicasting.) Also, I turn on IP 
Tunneling, though I'm not absolutely 
sure this is necessary. My testing is on 
Linux 2.2.x based kernels. 


Once, your AX25 network is running, 
you'll want to setup for IP Multicast. 
First, you need to set MULTICAST flag 
for all devices that use multicast. This is 
done with the following command: 


/sbin/ifconfig ax0 multicast’ 


Do a command "‘sbin/ifconfig' and you 
should see the word MULTICAST 
following each interface that you intend 
to use for multicast. My eth0O devices 
comes up with multicast on by default. 


Then, you need to change your routing. 
Make sure to 

‘add -net 224.0.0.0 netmask 240.0.0.0 
eth0' 


and 


‘add -net 224.0.0.0 netmask 240.0.0.0 
ax0' 


where eth0 is your local ethernet and ax0 
is your ham radio network. The net of 
224.0.0.0/4 is a special set of ip 
addresses set aside for ip multicast. 


Then you'll need to get mrouted up and 
running. I'll try to make versions 


Are You Still a 
NCPA Member? 


Please check the mailing 
label...Has your membership 
expired? If so, why not 
renew your membership now 
while you’re thinking about 
it? (There’s a form on the 
back cover.) 


If your membership 
expired in 1997, then this 
will be your last Downlink! 


Memberships have been 
extended to allow for the fact 
that the Downlink hasn’t 
come out quarterly, but this 
is it for those with 1997 
expirations. If you are in that 
category, but feel you should 
have more issues coming 
anyway, please contact us. 


available here, though mrouted is also 
available on the net. For mrouted to be 
useful, you'll need at least 2 networks or 
a tunnel. That is for example an ax25 
network and an ethernet network. Or an 
ethernet network and a tunnel to another 
ethernet network. 


I have a beacon test program which will 
send out multicast packets. With a 
beacon monitoring program, which I'm 
working on now, you should be able to 
see your beacons travel from one net to 
another. If you're connected to another 
user via a tunnel, you should see his 
beacons also. 


Then send me an email and either I'll 
connect your multicast network to my 
system, or hopefully find someone near 
you who can connect you. (I'm at 
cathryn@junglevision.com) 
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Here's how I start IP multicast: 


/sbin/route add -net 224.0.0.0 netmask 
240.0.0.0 ax2 

/sbin/route add -net 224.0.0.0 netmask 
240.0.0.0 ethO 

/sbin/ifconfig ax2 multicast 
/usr/sbin/mrouted 


You also might want to try 
/usr/sbin/mrouted -d 
To watch mrouted perform it's functions. 


If/usr/sbin/mrouted looks functional, it's 
time to setup the tunnels. The 
mrouted.conf file should be at 
/etc/mrouted.conf. Follow the 
instructions in mrouted.conf. (I'm 
currently working this out myself -- that 
is how to properly setup tunnels.) 


Finally, watch out for firewall issues. 


This one bit me for awhile. I run IP 
Multicast over an interface with 
masqueraded IP addresses. The second 
line sets up the IP Masquerading and the 
third line is necessary, in this example, 
to allow the interface to forward IP 
Multicast packets. 

/sbin/ipchains -P forward DENY 
/sbin/ipchains -A forward -s 
192.168.1.0/24 -j MASQ /sbin/ipchains 
-A forward -d 224.0.0.0/4 -] ACCEPT 


IP Multicast on Win98 


I have been testing small IP Multicast 
applications on Win98 and AX25 using 
the SV2AGW software. This 
combination works pretty good and can 
talk to Linux IP multicast with no 
problems. 


Win98 works well for running Multicast 
applications, but does not work as a 
multicast router. 


The MSDN website has some sample 
code for IP Multicast if you're interested 
in creating multicast applications for 
Wind98. 
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IP Multicast with NOS 


I don't run currently run any NOS code, 
so I'm not sure if these work or not. If 
you're a NOS programmer, give me the 
scoop and I'll put that information here. 


What is the Future? 


1. As a short term goal, I'd say it's 
important to get a few tunnels up and 
running, and verify the basic 
functionality of mrouted over ax25. 
Let's learn the basics of running IP 
Multicast. 


2. Develop beacons and _ beacon 
monitoring as an application. Sending 
and monitoring beacons is trivial from 
the programming side, but will give us 
some information on how well the 
tunnels are working. Also, beacons can 
possibly serve some use for distributing 
information widely across the ham radio 
networks around the world. A beacon 
system might be used to find people to 
meet on 20meters -- or to advertise a 
ham web page or something. Using ip 
multicast for beacons will also set up the 
right expectations about what the 
network is capable of doing. 


3. Develop a chat system. IP Multicast 
will allow us to make more scalable chat 
systems. Especially chat systems where 
many users are in the same chat room. 
Chat is slightly more advanced than 
beaconing, since there's an expectation 
that users will see all the messages that 
people type -- and this requires some 
kind of information to be stored by the 
users or in the network. 


4. Adapt existing IP Multicast 
multimedia applications to the ham radio 
network. These applications will 
probably run natively, but may require 
more bandwidth than we can give them. 
However, assuming some kind of 
bandwidth improvement in ham radio 
networking, (well, we can hope!) IP 
Multicast is a natural mechanism for 
delivering, for example, Newsline audio 
broadcasts to a wide variety of sites. 


Cathryn Mataga, KE6I 
http://ke6i.com 
cathryn@junglevision.com 


Minutes of the 
Annual Meeting 


Held at Pacificon ‘99 
October 17, 1999 


Sheraton Hotel, Concord CA 


Called to order 3 PM by president Gary 
WB6YRU. 


Attendance: Gary WB6YRU, Mike 
WAO6ZTY, Lloyd KD6FJI, Don 
KF6JMQ, Mel W6BNG, Joe KA6ROM, 
Barry KE6LW, Cathryn KEO6I, Art 
WO6THD, and Howard N6HM. 


Self introductions. 


Bylaw change regarding specification 
as to when we hold the general 
meeting 

(History: At the last general meeting 
Howard N6HM made a motion to 
change the bylaws to allow having the 
general meeting at Pacificon. The 
consensus was this should be done, but 
a change to the bylaws requires 
advanced notice to the membership. This 
issue will be voted on at the next general 
meeting.) 


The parts of the bylaws in question 
currently say: 

ARTICLE III Board of Directors 

A. The Association shall be run by 
a Board of Directors (Board) which 
shall each year originally consist of 
seven individuals elected at the April 
General Meeting to serve for one year 
beginning May 1. 

ARTICLE V_ General Meetings 

A. A GENERAL MEETING shall 
be held, as far as practical, every April. 


The following proposed changes (first 
sentence of each paragraph) removes 
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mention of the specific month when the 
annual general meeting should be held. 
This will allow meeting in the Fall at 
Pacificon or whenever. 

Article HI 

A. The Association shall be run by 
a Board of Directors (Board) which 
shall each year originally consist of 
seven individuals elected at the Annual 
General Meeting and have a term of one 
year. 

Article V 

A. An Annual General Meeting 
shall be held once per year, the time and 
date to be announced in the newsletter 
or by separate written notice at least 30 
days in advance. 


Approved unanimously. 


Treasurer's Report 

After the latest bills have been paid and 
the latest memberships are added, the 
treasury will have about $200. 
Discussion followed, including the 
following ideas and comments: 

Whether the newsletter comes out 
on time or not, memberships should 
expire "on time." We have been 
extending memberships to allow for the 
fact that the newsletter has not come out 
as often as it should. The consensus was 
to compromise between these two 
positions. 

We could solicit equipment 
donations and have a table at the flea 
market (but we'd need sufficient 
volunteers which are hard to come by). 

Sell kits (such as QRP, TAPR kits, 
etc). 

Sell Intro to Packet booklets again, 
but would need to update them from last 
time--need something new. 

Put 3x5 card up at HRO inviting 
NCPA membership. 

Make the Downlink more 
interesting by working harder to solicit 
articles from packet groups. Also solicit 
articles on specific topics rather than a 
general request for articles. 


Election of Directors 

N6HM reports Bob Vallio W6RGG (not 
present) wishes to run again as rep. of 
DXPSN. 
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Slate: 
Bob Vallio W6RGG 
Gary Mitchell WB6YRU 
Howard Krawetz NoHM 
Mel Gregonis W6BNG 
Barry Barnes KE6LW 
Mike Fahmie WA6ZTY 
Dave Harris NoUOW 
Bob Fahnestock WH6IO 

Dave N6UOW and Bob WH6IO 
were not present, but had expressed an 
interest inrunning. Before their election 
is finalized, their acceptance must be 
received. Also mentioned was Cap 
Pennel as a possible alternate for APRS 
if Dave is not willing to run again. 


Slate was approved unanimously. 


[Dave and Bob accepted shortly after 
this. --Ed.] 


New Digital sub-band at 433.0-434.0 
MHz. 
Keyboard needs two channels. 


N6HM: motion to leave 70 cm channel 
selection up to the coordinator. Passed 
unanimously (board will have override 
authority). 


Meeting with NARCC (few hours 
beforehand) 

One participant mentioned our new 
70 cm digital segment isn't new at all, 
but was agreed to be digital ten or twelve 
years ago between NARCC and NCPA. 
It's interesting that we ended up 
allocating (or re-allocating) the exact 
same segment independently. 

The meeting basically was an airing 
of past problems and agreement that 
everyone needs to work together on 
overall band planning. The consensus 
seemed to be that no one organization 
should dominate the band planning 
group. NARCC's president disagreed, 
wanted NARCC to "host" the band 
planning group. 


General Band Plan 

The board has been working on a 
general band plan in which the NCPA 
will officially recognize non-digital 
usage. This is intended for reference 


only--the NCPA is not proposing to do 
non-digital band planning. Consensus 
was that we should get NARCC in on 
this too. N6HM: motion to accept as is 
with the idea that it will be updated as 
new information comes in. The details 
will be up to the board. Passed 
Unanimously. 


Downlink 

Consensus is that the newsletter is very 
important. One idea for fund-raising is 
to have ads in the Downlink (want/for 
sale). Small ads from members would 
be free for the first 25 words or so, then 
perhaps 10 cents per word thereafter. 
Commercial ads would be at the "going 
rate" based on what other club 
newsletters are doing. 


Network traffic on 145.05 (keyboard) 
No new information/developments were 
mentioned. 


Adjourned 4:27 PM 


EOF 


News from 
the ARRL 


From Zhe ARRL Letter, Sept. 10, 1999 


FCC RELAXES RULES FOR 
SPREAD SPECTRUM 


The FCC has relaxed rules governing the 
use of spread spectrum techniques by 
radio amateurs and opened the door to 
the possibility of international spread 
spectrum communication. The Report 
and Order in WT Docket 97-12 adopted 
August 31 concludes a proceeding that 
originated with an ARRL petition in 
December 1995 and has been pending 
since 1997. 


The FCC adopted rules that will allow 
Amateur Radio stations to transmit 
additional spread spectrum emission 
types. Once the new rules become 
effective November 1, hams will be able 
to use techniques other than frequency 

hopping and direct sequence spreading. 
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Location 


California City 


Castro Valley 
Chico 


Hanford 


Livermore 
Los Gatos 


Mountain View 
Oakdale 
Penngrove 
Reno, Nevada 


Rio Linda 
San Francisco 


Bob Vallio - W6RGG 


In addition, the new FCC rules will 
permit US hams to use spread spectrum 
techniques to communicate with 
amateurs in other countries that permit 
SS. Spread spectrum communication 
has been limited to stations within FCC 
jurisdiction. 


The new rules require that spread 
spectrum stations running more than | 
W incorporate automatic transmitter 
power control. Amateur stations using 
SS are restricted to a maximum power of 
100 W. 


The Commission also amended the rules 
to eliminate what it called 
"now-unnecessary record keeping and 
station identification requirements" that 
apply only to stations using spread 
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DX Spotting Nodes 


June 1999 
Alias Frequency 


-490 


Coverage 


Antelope Valley area 


-490 
.770 
.670 
.670 
. 950 
950 
.770 
.770 
.770 
.580 
.580 
950 
.580 
. 950 


Chico 


580 
950 
.500 
. 950 
.670 


Low 


(2400 baud) 


Orr ADF RDA DDOVOVHOP POO OP 


wsixrgg@crl.com 


spectrum. The FCC agreed to let SS 
stations identify themselves using 
conventions developed by the Amateur 
Radio community. 


Roanoke Division Vice Director Dennis 
Bodson, W4PWF, who has followed the 
League's Spread Spectrum initiative 
through from start to finish was pleased 
with the outcome of the proceeding. "I'm 
very happy," he said. "The League got 
everything it wanted and more--all of 
which, I believe, will help to promote 
this mode on the amateur bands." 
Bodson served as the ARRL Board 
liaison with the Future Systems 
Committee and chaired the Ad Hoc 
Committee on Spread Spectrum, which 
was instrumental in developing the 
League's stance on Spread Spectrum. 


Oroville, 
South Fork Mtn - Redding area 
Bear Mtn, 


Mt. Adelaide, 


Oak Peak 
East, West, 


South SF Bay area 


Red Bluff 


Fresno area 
Bakersfield area 


Oakhurst 
Tri-Valley area 
Santa Cruz Mtns, 
Santa Cruz/Los Gatos 
Mountain View, 
Modesto area 
Sonoma County 
-950,146.58,441.500 


Virginia City, 


Sacramento, 


Monterey Bay 


San Jose area 


(2400 baud), 51.7 


Level in Reno 


NV 


Woodland, Davis 


East Bay and North 


Stations employing spread spectrum 
techniques will remain secondary to--and 
must accept all interference 
from--stations employing other 
authorized modes. The FCC declined to 
authorize the use of spread spectrum 
techniques on additional bands or 
frequencies. 


A copy of the FCC's complete Report 
and Order is available at 
http://www.arrl.org/announce/regulator 
y/wt97-12. 


From The ARRL Letter, Oct. 29, 1999 


FCC REVISES CONDUCTED 
EMISSION LIMITS 
The FCC has 


gone along with 
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Packet Sysops of Northern California 
Packet Bulletin Board Systems 
November 1999 


Call-SID Location 


Benica 


Berkeley 
Berkeley 


Exeter 
Fremont 
Gilroy 
Gatos 


LOS 


Redding 
Richmond 
Richmond 
San Jose 
San Jose 
Sebastopol 
Sonora 


tockton 
Walnut Creek 
Willits 

Yuba City 


9600 Baud Port 
TCP/IP Port 
Currently Inactive 


recommendations from the ARRL and 


others to hold the line on conducted 
emissions below 30 MHz _ from 
unlicensed consumer electronic and 
industrial, scientific and medical devices 
operating under Parts 15 and 18 of the 
Commission's rules. The FCC has 
proposed new emission guidelines that 
are just slightly more stringent than the 
current FCC standards. 


"We conclude that mandatory conducted 
emission limits continue to be necessary 
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Citrus Heights 


North Highlands 


South Lake Tahoe 
Stanford Univ 


User Ports 


433.43&+ 


ic okay 
i713 
O07, 
rl 

2 OF 

fb O 
99 

Po Be 
sly 
O37 


433.37&* 


441.50& 


145.71&+ 
145.69 
441.50 


ssi: Se. pi oP oS eT Ba eB: oT pf a: oc TS oS oe ce a a a Ba eS oe BS a 
OpKR ROB KROOKRoOROoOBKRP RR ROO BOW 


to control interference to 
communications services," the FCC said 
in a Notice of Proposed Rule Making in 
ET Docket 98-80, released October 18. 
The Commission announced plans to 
"harmonize" its conducted emission 
standards with international standards 
developed by the International 
Electrotechnical Commission, 
International Special Committee on 
Radio Interference--known as CISPR. 


The CISPR emission limits for 
consumer equipment are "approximately 


5 dB more stringent below 5 MHz and | 
dB more stringent above 5 MHz" than 
the existing standards, the FCC said. 
"We believe that these standards address 
some of the concerns expressed by 
ARRL" and others in response to last 
year's FCC Notice of Inquiry on the 
issue, the Commission commented. 


The Commission said it was not 
persuaded by a National Association of 
Broadcasters' suggestion to impose 
much tighter standards--22 dB greater 


than present--to protect AM 
broadcasting. 
Interfering devices include such 


common household appliances as 
computers, TV sets, and microwave 
ovens. Conducted emissions result from 
RF voltages imposed on the ac power 
line, which can in turn act as an antenna. 
In general, the FCC's current conducted 
emissions limit is 250 uV. Equipment 
manufacturers had argued to relax 
existing limits to keep down production 
costs, while the ARRL and others 
representing spectrum users had asserted 
that the existing limits were not tight 
enough. In response to the earlier NOI, 
the League had commented that the 
proliferation of Part 15 and 18 devices 
over the past decade had resulted in "a 
marked increase in RF noise from 
conducted emissions generally." 


The FCC said it agrees that standards on 
the amount of RF energy conducted onto 
the ac power lines "are required to 
control potential interference to users of 
the radio spectrum below 30 MHz." It 
also invited comments on expanding the 
frequency range of the conducted 
emission limits from the current 450 to 
30 MHz to the 9 kHz to 30 MHz spelled 
out in the CISPR standards. The ARRL 
has proposed that the FCC allocate new 
LF amateur bands at 136 kHz and at 160 
to 190 kHz. 


Comments on the NPRM are due 75 
days after its publication in The Federal 
Register, and reply comments are due 30 
days later. A copy of the FCC's Notice 
of Proposed Rule Making in ET Docket 
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98-80 is available at http://www.arrl.org/ 
announce/regulatory/et98-80/nprm.html. 


FCC ALLOCATES 75 MHz AT 5.9 
GHz FOR ITS 


As expected, the FCC has allocated 75 
MHz of spectrum in the vicinity of 5.9 
GHz for use by so-called "Intelligent 
Transportation System" services aimed 
at improving highway safety. The 
co-primary allocation for Dedicated 
Short Range Communications systems at 
5.850 to 5.925 GHz includes the upper 
portion of a secondary Amateur Service 
allocation. Hams share 5.650 to 5.925 
GHz with government radars and 
nongovernment fixed satellite service 
uplinks. The FCC already has allocated 
5.725-5.825 GHz for U-NII devices to 
provide short-range, high-speed wireless 
digital communication under Part 15. 


In releasing its Report and Order in ET 
Docket 98-95 October 22, the FCC said 
the 5.850-5.925 GHz band would be 
devoted to a variety of Part 90 DSRC 
uses such as traffic light control, traffic 
monitoring, travelers’ alerts, automatic 
toll collection and traffic congestion 
detection. Other proposed uses of ITS 
would include electronic inspection of 
moving trucks and emergency vehicle 
traffic signal preemption. The 
Commission said that amateur 
organizations and licensees "raised the 
majority of DSRC spectrum sharing 
concerns" in their comments on last 
year's Notice of Proposed Rulemaking 
on the issue. 


In its September 1998 comments, the 
ARRL said the FCC was proposing too 
much spectrum at 5.9 GHz for DSRC 
deployment. The League had asked that 
the FCC compensate the Amateur 
Service by elevating remaining Amateur 
and Amateur Satellite allocations at 
5.650 to 5.725 and 5.825 to 5.850 GHz 
to nongovernment primary "to insure 
against future preemption by 
nongovernment services with higher 
allocation status." The FCC Report and 
Order did not specifically address the 
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ARRL's request for elevation to primary 
status, however. 


In the R&O, the FCC said it was 
"sympathetic" with the League's 
concerns that the ITS and U-NII 
allocations could impact amateur use in 
the band but said hams have 275 MHz in 
the band and most ham use is for 
point-to-point networks. Given amateur 
radio's inherent frequency agility, the 
FCC said it believes "spectrum sharing 
between the amateur service 
point-to-point links and DSRC 
operations is viable." DSRC operations 
in the 5.850-5.925 GHz band "are 
unlikely to receive significant 
interference from or cause interference 
to amateur operations," the FCC said. 


The FCC encouraged ITS entities to 
"informally notify the ARRL or the local 
amateur service community" of their 
intended operation. The FCC has 
proposed a maximum of 30 W EIRP for 
DSRC systems, but the rules will require 
ITS licensees to use the minimal power 
necessary. 


The FCC says it will defer consideration 
of licensing and services rules and 
spectrum channelization plans to a later 
proceeding. 


From The ARRL Letter, Dec. 10, 1999 


TAPR RELEASES DRAFT APRS 
PROTOCOL SPEC 


The APRS (Automatic Position 
Reporting System) Working Group has 
completed the second public draft of the 
APRS Protocol Specification. 


This document covers the core 
functionality of APRS Protocol Version 
1.0 as it works today. This is the 
base-level specification that all 
implementations should comply with. It 
was adopted unanimously by Working 
Group members, who include the authors 
of APRS-DOS, WinAPRS, MacAPRS, 
X-APRS, PocketAPRS, APRS+SA, 
javAPRS, and APRServe, and the 


developers of the Mic-E and Pic-E 
products. 


The Specification now includes packet 
format diagrams, the APRS symbol 
tables, full details of the Mic-E encoded 
format, the compressed 
latitude/longitude position format, plus 
weather report and telemetry formats. 
Above all, the Specification contains 
many examples of how APRS data is 
formatted to make it easier to 
understand. 


The APRS Protocol Specification draft 
now is available as an Adobe PDF file at 
http://www.tapr.org/tapr/html 
/Faprswg.html. Comments, criticisms 
and suggestions for improvement are 
invited, and the document includes 
details on how to file comments. 


The comment deadline is midnight 
Pacific Time Sunday, December 19, 
1999 (0800 UTC, Monday December 
20, 1999). The APRS Working Group 
will issue the final approved version of 
the Specification as soon as possible 
after it considers all comments. 


--John Ackermann, N8UR. 


EOF 


Board of Directors 
Electronic Meeting 


Excerpts of the NCPA board remailer 
traffic, July 1999 through September 14 


1999. Compiled by Gary Mitchell 
WBOYRU (full text of traffic is 
available). 


July 4, 1999 

Louis Cobet, KEMDH: 

The FCC assigned RM-9673 to a 
petition by the Central States VHF 
Society. I think everyone interested in 
band planning and digital work between 
6 meters and 70 cm will be interested in 
this proposal for rule making. The 
proposed rule changes would harden into 
part 97 the band plan that the Central 
States VHF Society wants. 


Fall, 1999 


Zonker Harris: 
The two-meter "no data" clause seems to 
be a problem. 


FCC has issued an NPRM number, and 
the comment window opened 6/28... do 
we want to draft something as a group, 
or respond individually? 


From the NPRM: 

144.3-148.0 MHz: Delete RTTY, data, 
test, and MCW. Also delete reference to 
Standard 8. Note: this would prevent 
packet radio from operating anywhere 
in the two-meter band, which is 
probably not intended. 


[The latest word is that the FCC has 
dismissed many proposed rule changes, 
including this one. --Ed.] 


July 6, 1999 

Vote to accept list of simplex 
frequencies, except for 146.595 (to be 
figured out later): 

Five YES 

Zero NO 

One not voting 

The motion passes. 


July 17, 1999 

R. B. Vallio, W6RGG 

Please delay any vote on 146.595 until I 
am able to provide you with some 
confirmed new information. 


July 18, 1999 

R. B. Vallio, W6RGG: 

withdraws motion for 146.595 to be 
digital. 


July 20, 1999 

Gary Mitchell, WB6YRU: 

(Listed repeater channels for band plan, 
plus a few comments) 


August 2, 1999 

Gary Mitchell, WB6YRU: 

(Posted examples of how the band plans 
could be listed) 


Discussion followed about how to 
present the information so that it would 
provide a lot of data at a glance, yet fit 
on most text screens. 


Bob Vallio, W6RGG: 


Changes have been made to the reflector 
which should preclude the further receipt 
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of commercial messages. No one who is 
not registered on the reflector may post 
messages. No one is prevented from 
joining the reflector, as long as they are 
willing to confirm their address via 
return e-mail. I hope this proves 
satisfactory to everyone. 


Cap Pennell, KE6AFE: 
Reports that Bill Bliss WB6LPG died. 


August 5, 1999 

Gary Mitchell, WB6YRU: 

Regarding amateur usage of 33 cm... 
WSWSS (Western States Weak Signal) 
president described their usage and 
referred me to a SCRRBA's web page, 
http://www.scrrba.org/BandPlans/ 
33cmnotes.html. 


The NCPA plan for digital at 33 cm has 
remained unchanged for a very long 
time, almost all of it is classified as 
experimental (i.e. not specifically 
allocated). Perhaps it's time we 
re-evaluate it. 


(Listed band plan of NCPA, WSWSS, 
and SCRRBA for 33 cm) 


August 9, 1999 

Gary Mitchell, WB6YRU: 

WHOIO and K6TPK are currently using 
51.16 (a keyboard channel) for 
forwarding. A request has been made to 
allocate a six meter channel for 9600 
baud TCP/IP. Once this is done, they'll 
move off of 51.16 to the designated 
channel. 51.62 - 51.68 are currently 
un-allocated 20 kHz digital channels. 


The recommendation is to allocate 51.62 
MHz to 9600 baud TCP/IP. 

Four YES 

Zero NO 

One ABSTAIN 

One not voting 

The motion passes. 


August 10, 1999 

Gary Mitchell, WB6YRU 

It seems we won't be getting anything 
out of our editor. So, it looks like this 
very belated issue is going to have to 
start up again from scratch. I'm willing 
to do this issue, but we really (still) need 
an editor. In the mean time, does anyone 
have anything in the way of articles for 
this issue? 


Charles Brabham, NS5PVL 
Suggests something on FlexNet 
(provides web page for info) 


August 26, 1999 

Gary Mitchell, WB6YRU 

(Posts sample of overall band plans for 
10 through 1.25 meters, asks for 
comments) 


(Couple of minor comments followed) 


August 30, 1999 
Bob Fahnestock, WH6IO forwards 
message from the 
Ham-L@kc3ol.dynip.com list: 

The United Kingdom will move from 
25 kHz to 12.5 kHz channel spacing on 
2 meters starting January 1, 2000, much 
in the same manner that the US went 
from 30-kHz to 15-kHz spacing years 
ago. Eventually all 2-meter repeaters in 
ITU Region I will conform to the 
12.5-kHz standard. The same change is 
under consideration for 70-cm repeaters 
as well.--RSGB; Newsline 


Sept 3, 1999 

Gary WB6YRU: 

Posts rough draft of overall band plan 
Howard N6HM 

Treasurers report -- we have only 


$198.07, not good. Allan W6MEO, 
Steve KA6ETB, and Bob WH6I0O 
pledge to donate $25 each. 


Sept. 11, 1999 

Gary WB6YRU 

Posts information on 33 cm band and 
how So. CA has done band planning 
there. 


Sept 14, 1999 

Gary WB6YRU 

Announces general meeting at Pacificon 
NARCC has new president: John Ronan 
K3ZJJ (also running for Pac. Div V.P.) 
And many new people on their board. 
John mentions Spectrum management 
meeting at Pacificon. 


EOF 
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Northern California Packet Band Plan 
November 1999 


50 MHz 


50.60-50.80 (20 kHz channels, non-specific at this time) 
51.12 SCA backbone 

51.14 BBS 

51.16 Keyboard to Keyboard 

51.18 Experimental 

51.62 TCP/IP, 9600 baud 

51.64-51.68 (20 kHz channels, non-specific at this time) 


144 MHz 


144.31 BBS 

144.33 Balloon & experimental 

144.35 Keyboard to Keyboard 

144.37 BBS LAN forwarding 

144.39 APRS (U.S. and Canada) 

144.41 duplex, lower half (145.61 upper half, 1.2 MHz split) 
144.43 TCP/IP (OK to run duplex with 145.65) 
144.91 Keyboard to Keyboard 

144.93 BBS 

144.95 DX Spotting 

144.97 BBS 

144.99 BBS 

145.01 User access 

145.03 Keyboard to Keyboard 

145.05 Keyboard to Keyboard 

145.07 BBS 

145.09 BBS 

145.61 duplex, upper half (144.41 lower half) 
145.63 BBS 

145.65 TCP/IP 9600 bps (OK to run duplex with 144.43) 
145.67 DX Spotting 

145.69 BBS 

145.71 9600 bps 

145.73 BBS 

145.75 TCP/IP 

145.77 DX Spotting 

146.58 DX Spotting 


NOTES: 
¢ Allocations from 144.31 through 144.43 are relatively close to the 
weak-signal sub-band--watch your deviation. 


220 MHz 


219.05-219.95 100 kHz channels, Backbone 
223.54 LAN 

223.56 LAN 

223.58 LAN, Gilory (GARLIC) 

223.60 LAN, Sacramento Valley (SACVAL) 
223.62 LAN, South Bay (SBAY) 

223.64 TCP/IP 

223.66 Keyboard to Keyboard 

223.68 DX Spotting Backbone 

223.70 LAN, Monterey Bay & North Coast (MRYBAY) 
223.72 LAN, North Bay (NBAY) 
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223.74 Backbone, DX Spotting 


NOTES: 

¢ 219 channels are by coordination only. There are currently 
political problems with using 219-220, making them unavailable in 
most of northern CA. 

¢ On 223.58, TCP/IP interlink (Sacramento) is secondary, not to 
interfere with node uplink. 

¢ 222.14 was recognized as weak signal and the existing DX 
spotting stations moved to 223.68 on March 7, 1999. At 

the same time, 223.68 was changed to DX Backbone. 


440 MHz 


433.05 TCP/IP backbone (100 kHz) 

433.15 BBS backbone (100 kHz) 

433.25 DX Spotting backbone (100 kHz) 

433.31 - 433.35 (20 kHz channels non-specific at this time) 
433.37 BBS, 9600 baud 

433.39 DX Spotting 

433.41 BBS LAN 

433.43 9600 baud TCP/IP 

433.45 BBS LAN 

433.47 Keyboard Interlink 

433.49 TCP/IP 

433.51, 433.53 (20 kHz channels non-specific at this time) 
433.55 BBS LAN 

433.51 - 434.0 (20 kHz channels non-specific at this time) 
441.50 Any 


NOTES: 

¢ Channel allocation in this band is currently under review. 

¢ There is a possibility of duplex channels being assigned in the 
future (probably 433.x/438.x MHz). Comments are welcome. 


900 MHz 


903.500 1 MHz wide, TCP/IP 
904.500 1 MHz wide, TCP/IP 
915.500 1 MHz wide, experimental 
916.100 200 kHz wide, experimental 
916.300 200 kHz wide, experimental 
916.500 200 kHz wide, experimental 
916.650 100 kHz wide, experimental 
916.750 100 kHz wide, experimental 
916.810 20 kHz wide, experimental 
916.830 20 kHz wide, experimental 
916.850 20 kHz wide, experimental 
916.870 20 kHz wide, experimental 
916.890 20 kHz wide, experimental 
916.910 20 kHz wide, experimental 
916.930 20 kHz wide, experimental 
916.950 20 kHz wide, experimental 
916.970 20 kHz wide, experimental 
916.990 20 kHz wide, LAN links (Contra Costa County only) 


900 MHz activity is on a non-interference basis to vehicle locator 
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service. This sub-band is not considered suitable for 
omnidirectional systems. Use for point-to-point links only. 


1296 MHz 


1248.500 1 MHz wide, experimental * 
1249.000-1249.450 Unchannelized, experimental 
1249.500 100 kHz wide, experimental 

1249.600 100 kHz wide, experimental 

1249.700 100 kHz wide, experimental * 

1249.800 100 kHz wide, experimental” 

1249.870 20 kHz wide, experimental 

1249.890 20 kHz wide, DX Packet Spotting 
1249.910 20 kHz wide, experimental’ 

1249.930 20 kHz wide, experimental” 

1249.950 20 kHz wide, experimental” 

1249.970 20 kHz wide, experimental” 

1249.990 20 kHz wide, experimental” 

1250.500 1 MHz wide, experimental 

1251.500 1 MHz wide, experimental 
1297.000-1298.000 Unchannelized, experimental 
1298.500 1 MHz wide, experimental” 
1299.000-1299.450 Unchannelized, experimental 
1299.500 100 kHz wide, experimental 

1299.600 100 kHz wide, experimental 

1299.700 100 kHz wide, experimental” 

1299.800 100 kHz wide, experimental” 

1299.870 20 kHz wide, BBS LAN 

1299.890 20 kHz wide, DX Packet Spotting 
1299.910 20 kHz wide, BBS LAN 

1299.930 20 kHz wide, experimental” 

1299.950 20 kHz wide, experimental” 

1299.970 20 kHz wide, experimental” 

1299.990 20 kHz wide, experimental” 


* Full duplex channel pairs at 50 MHz separation, example: 
1249.910 <> 1299.910 


Definitions 


9600 BPS Stations using 9600 baud with direct FSK (G3RUH, 
TAPR, etc.) modems. 


Backbone No uncoordinated stations. These channels are for 
specific purposes as defined by the NCPA and/or affiliated groups. 
These are frequencies where the various BBS, nodes, and networks 
forward traffic and are very high volume channels. Please use the 
normal user entry points of the network you want to access rather 
than these channels. 


BBS These frequencies are for user access to a full-service BBS. 
Keyboard-to-keyboard is tolerated. Please don't put high level 
nodes or digipeaters on these channels since they are local. A 
low-level direct link or node that links into a backbone on another 
frequency is the proper implementation. 


Duplex Simultaneous transmit and receive by a single station, 
including digital repeaters. Duplex channels are intended for 
high-volume applications. 9600 baud or higher is encouraged, but 
not required at this time. 


DX Spotting Northern California DX packet spotting network. No 
other activity should be on these channels. 
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Experimental Anything goes except full service BBS or any 24 
Hr/Day services (nodes, gateways, etc). This is where you can test 
new gear, programs, etc. These channels may be reassigned in the 
near future, so no permanent activities please. 


Forwarding same as backbone 


Keyboard to Keyboard Primarily chat channels. These are also 
the primary emergency channels. No high-volume activity such as 
full service BBS, DX Spotting, TCP/IP, etc. 


Interlink same as backbone 


LAN Local Area Network. BBS's are grouped into LAN's for more 
efficient forwarding. A LAN frequency is the forwarding channel 
within a LAN and to the backbone. Please do not attempt to access 
the BBS network on these channels. 


Personal _mailbox/maildrop A BBS-like system, often running 
entirely within a TNC, with a small number of users that handles 
information of a personal, local or special-purpose nature. A 
mailbox is allowed on keyboard-to-keyboard channels ONLY if it 
does not forward with other BBSs. Mailboxes may forward with 
full-service BBSs on LAN channels at the discretion of the BBS 
SYSOP. 


TCP/AP Stations using TCP/IP protocol on top of AX.25. Some 
AX.25 tolerated to communicate to TCP/IP stations if a compatible 
p-persistence access method used. 


User_Access User access to a network. This is for the next 
generation of packet which is expected to operate like the internet. 
Users would access such a network on these frequencies. The load 
on these channels may be rather high, like BBS channels. The 
activity may be any combination of BBS, keyboard, TCP/IP, or 
other modes. 


Procedure for changes 


Send requests for changes to either the frequency coordinator or the 
NCPA board. The frequency coordinator will then present the 
request to the board along with suggested assignments. The NCPA 
board, elected by you, the packet user, makes all assignments. 


Misc. Info. 


Packet tends to splatter if the deviation is set too high. Please keep 
your deviation to less than 5 kHz. 


Except for the 219-220 MHz segment, the NCPA currently does not 
coordinate individual stations, nodes, etc. leaving that to the special 
interest groups. BBS station coordination is done by the PSNC in 
Northern CA. DX spotting is coordinated by DXPSN. Some 
digital has been coordinated on auxiliary channels by NARCC. 


The NCPA board conducts most of its meeting activity 
electronically by internet e-mail remailer, ncpa@qth.net. As with 
face-to-face board meetings, interested persons are welcome. 
Subscribe to the remailer by sending e-mail to majordomo@qth.net 
with "subscribe ncpa" as the message. Subscribing to the remailer 
is like attending a continuous NCPA board meeting. 
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Northern California Packet Association 


The NCPA fosters digital communications modes of amateur radio through education, band planning, and acts as an 
umbrella organization for various packet special interest groups. Your annual dues helps pay for this newsletter and other 
educational materials activities. If you might be interested in getting more involved, please let us know. 


Call: Home BBS: e-mail: 


Address: 


City: Zip + 4: Phone: 


CO New Membership Renewal Change of Address O I’m an ARRL Member 
O One year: $10 O Two Years: $20 Three years: $30 
(make checks payable to NCPA) 


Please indicate your area(s) of interest: 
O BBS SysOp © BBS User O APRS O NET/ROM TCP/IP O High-speed packet 
DX Packet Spotting Network © Keyboard to Keyboard FCC/legal issues O Other: 


NCPA Downlink 

Northern California Packet Association 
PO BOX 61716 

Sunnyvale CA 94088-1761 


First Class 


